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Abstract 
Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) 
exist on the signaling and media paths between the endpoints. This 
document describes the behavior of B2BUAs when Secure Real-time 
Transport (SRTP) security context is set up with the Datagram 
Transport Layer Security (DTLS) protocol. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7879. 
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1. Introduction 
1.1. Overview 


[RFC5763] describes how the Session Initiation Protocol (SIP) 
[RFC3261] can be used to establish a Secure Real-time Transport 
Protocol (SRTP) [RFC3711] security context with the Datagram 
Transport Layer Security (DTLS) protocol [RFC6347]. It describes a 
mechanism for transporting a certificate fingerprint using the 
Session Description Protocol (SDP) [RFC4566]. The fingerprint 
identifies the certificate that will be presented during the DTLS 
handshake. DTLS-SRIP is currently defined for point-to-point media 
sessions, in which there are exactly two participants. Each DTLS- 
SRTP session (described in Section 3 of [RFC5764]) contains a single 
DTLS connection (if RTP and RTP Control Protocol (RTCP) are 
multiplexed) or two DTLS connections (if RTP and RTCP are not 
multiplexed), and either two SRTP contexts (if media traffic is 
flowing in both directions on the same 5-tuple) or one SRTP context 
(if media traffic is only flowing in one direction). 


In many SIP deployments, SIP Back-to-Back User Agents (B2BUA) 
entities exist on the SIP-signaling path between the endpoints. As 
described in [RFC7092], these B2BUAs can modify SIP and SDP 
information. For example, as described in Section 3.1.3 of 
[RFC7092], SDP-modifying signaling-only B2BUAs can potentially modify 
the SDP. B2BUAs can also be present on the media path, in which case 
they modify parts of the SDP information (like IP address, port) and 
subsequently modify the RTP headers as well. Such B2BUAS are 
referred to as "media-plane B2BUAS". [RFC7092] describes two 
different categories of media-plane B2BUAsS, according to the level of 
activities performed on the media plane. 


When B2BUAS are present in a call between two SIP User Agents (UAs), 
they often make end-to-end DTLS-SRTP sessions impossible. An "end- 
to-end DTLS-SRTIP session" means that man-in-the-middle devices cannot 
break the DTLS-SRTP session between the endpoints. In other words, 
the man-in-the-middle device cannot create a separate DTLS-SRIP 
session between the client and the middle device on one side, and the 
middle device and the remote peer on the other side. B2BUAs may be 
deployed for address hiding or media latching [RFC7362], although 
Traversal Using Relays around NAT (TURN) and Interactive Connectivity 
Establishment (ICE) are expected to be used more often for this 
purpose as it provides better security properties. Such B2BUAS are 
able to perform their functions without requiring termination of 
DTLS-SRTP sessions, i.e., these B2BUAs need not act as DTLS proxy and 
decrypt the RTP payload. 
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1.2. Goals and Scope of this Document 


A B2BUA could be deployed for address hiding or media latching as 
described in [RFC7362]. Such B2BUAs only terminate the media plane 
at the IP and transport (UDP/TCP) layers and may inspect the RTP 
headers or RTP Control Protocol (RTCP) packets. The goal of this 
specification is to provide guidance on how such B2BUAs function 
without breaking the end-to-end DTLS-SRTP session. A B2BUA could 
also terminate the media, or modify the RTP headers or RTP Control 
Protocol (RTCP) packets. Such B2BUAs will not allow end-to-end DTLS-— 
SRTP. The recommendations made in this document are not expected to 
be applied by B2BUAs terminating DTLS-SRTP sessions given deployment 
reality. 


This specification assumes that a B2BUA is not providing identity 
assurance and is not authorized to terminate the DTLS-SRIP session. 

A B2BUA that provides identity assurance on behalf of endpoints 
behind it can modify any portion of SIP and SDP before it generates 
the identity signature. As the B2BUA is generating the identity 
signature, it is not possible to detect if a B2BUA has terminated the 
DTLS-SRTP session. B2BUAsS providing identity assurance and 
terminating DTLS-SRTIP sessions are out of scope of this document. 


The following sections describe the behavior B2BUAs can follow to 
avoid breaking end-to-end DTLS-SRTIP sessions. 


2. Terminology 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 

document are to be interpreted as described in [RFC2119]. 

Transport Address: The combination of an IP address and port number. 

The following generalized terms are defined in [RFC3261], Section 6. 
B2BUA: A SIP Back-to-Back User Agent, which is the logical 
combination of a User Agent Server (UAS) and a User Agent Client 
(UAC). 
UAS: A SIP User Agent Server. 


UAC: A SIP User Agent Client. 


All of the pertinent B2BUA terminology and taxonomy used in this 
document are based on [RFC7092]. 
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4. 


It is assumed the reader is already familiar with the fundamental 
concepts of the RTP protocol [RFC3550] and its taxonomy [RFC7656], as 
well as those of SRTP [RFC3711] and DTLS [RFC6347]. 


B2BUAS Procedures to Allow End-to-End DTLS-SRTP 


A B2BUA MUST follow the rules mentioned below to allow end-to-end 
DTLS-SRTP sessions. 


1. B2BUAs MUST forward the certificate fingerprint and SDP setup 
attribute it receives from one endpoint unmodified towards the 
other endpoint and vice versa. 


2. The enhancements described in [RFC4474] provide a means for 
signing portions of SIP requests in order to provide identity 
assurance and certificate pinning by providing an identity 
Signature over the SDP that carries the fingerprint of keying for 
DTLS-SRTP [RFC5763]. B2BUAS can identify that the enhancements 
in [RFC4474] are used for identity assurance if the SIP request 
contains both Identity and Identity-Info headers. In cases where 
endpoints use [RFC4474], B2BUAs MUST ensure that it does not 
modify any of the information used to construct the identity 
signature. This includes the entire SDP body and portions of the 
SIP header as described in [RFC4474]. In this case, a B2BUA 
cannot act as a media-relay B2BUA. 


3. [SIP-ID] is introduced to overcome the limitations of [RFC4474] 
(discussed in Section 1 of [SIP-ID]). Unlike [RFC4474], [SIP-ID] 
does not generate an identity signature over material that 
intermediaries in the field commonly alter. In this case, a 
B2BUA can act as a media-relay B2BUA. B2BUAs can identify that 
[SIP-ID] is used for identity assurance if the SIP request 
contains an Identity header but does not include an Identity-Info 
header. The Identity-Info header is deprecated in [SIP-ID]. A 
B2BUA MUST ensure that it does not modify any of the headers used 
to construct the identity signature. 


4. Both media relays and media-aware relays MUST NOT modify the 
authenticated portion of RTP and RTCP packets, and MUST NOT 
modify the authentication tag in the RTP and RTCP packets. 


Signaling-Plane B2BUA Handling of DTLS-SRTIP 
Section 3.1 of [RFC7092] describes different categories of signaling- 


plane B2BUAs. This section explains how these B2BUAs are expected to 
comply with the recommendations in Section 3. 
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4. 


4 


IR 


Dis 


1. Proxy-B2BUASs 


Proxy-B2BUAs, as defined in Section 3.1.1 of [RFC7092], modify only 
the Via and Record-Route SIP headers. These B2BUAsS can continue to 
perform their function and still allow end-to-end DTLS-SRTP sessions 
since none of the headers used to construct the identity signature 
are modified. 


-2. Signaling-Only and SDP-Modifying Signaling-Only B2BUAs 


These categories of B2BUAS are likely to modify headers that are used 
to construct the identity signature. For example, a signaling-only 
B2BUA can modify the Contact URI. Such B2BUAs are likely to violate 
rule 2 or rule 3 in Section 3. Depending upon the application 
requirements, such a B2BUA may be able to limit modification of 
header fields to those allowed to be modified by [RFC4474] or 
[SIP-ID]. 


Media-Plane B2BUA Handling of DTLS-SRTP 
1. General 
This section describes how the different types of media-plane B2BUAS 


defined in [RFC7092] are expected to comply with the recommendations 
in Section 3. 


-1.1. Media Relay 


From an application-layer point of view, a media relay (as defined in 
Section 3.2.1 of [RFC7092]) forwards all packets it receives on a 
negotiated connection, without inspecting or modifying the packet 
contents. A media relay only modifies the transport layer (UDP/TCP) 
and IP headers. 


A media-relay B2BUA follows rule 1 mentioned in Section 3 and 
forwards the certificate fingerprint and SDP setup attribute it 
receives from one endpoint unmodified towards the other endpoint and 
vice versa. The following example shows a SIP call establishment 
flow, with both SIP endpoints (user agents) using DTLS-SRTP, anda 
media-relay B2BUA. 
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+------- + PS SSe a SaaS R SSS + Hass + 
| Alice | | Media-Relay B2BUA | | Bob | 
+------- + hese See So See eS + +----- + 
(1) INVITE (3) INVITE 
a=setup:actpass a=setup:actpass 


a=fingerprintl | a=fingerprintl 
(Alice’s IP/port) | (B2BUAs IP/port) 


<------------------------ | 
| (4) 100 trying 
|<-------------------------- 
| 
| (5) 200 OK 
a=setup:active 
| a=fingerprint2 
| (Bob's IP/port) 
<------------------------ | <-------------------------- 
(6) 200 OK | 
a=setup:active | 
a=fingerprint2 
B2BUAs IP/port 
(7, 8) ClientHello + use_srtp 
< Se et Oe SO ee eee ee SS SS SS SS Se a eS SS SS E eee 


(B2BUA changes transport (UDP/TCP) and IP header) 


(9,10) ServerHello + use_srtp 


eh dS ls di ts a el nas nd rae el tay a es el a es A a es eel re a me Se el rik lt i ans act el ee at > 
| (B2BUA changes transport (UDP/TCP) and IP header) 
(11) | 
[Certificate exchange between Alice and Bob over 
|  DTIS ] | 
| (12) | 
| <--------- SRTP/SRTCP----------- SRTP/SRTCP----------- > 


[B2BUA changes transport (UDP/TCP) and IP headers] 
Figure 1: INVITE with SDP Call Flow for Media-Relay B2BUA 


Note: For brevity, the entire value of the SDP fingerprint attribute 
is not shown. The example here shows only one DTLS connection for 
the sake of simplicity. In reality, depending on whether the RTP and 
RTCP flows are multiplexed or demultiplexed, there will be one or two 
DTLS connections. 
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If RTP and RTCP traffic is multiplexed on a single port as described 
in [RFC5761], then only a single DTLS connection is required between 
the peers. If RTP and RTCP are not multiplexed, then the peers would 
have to establish two DTLS connections. In this case, after 
receiving an INVITE request, Bob triggers the establishment of a DTLS 
connection. Note that the DTLS handshake and the sending of the 
INVITE response can happen in parallel; thus, the B2BUA has to be 
prepared to receive DTLS, Session Traversal Utilities for NAT (STUN), 
and media on the ports it advertised to Bob in the SDP offer before 
it receives an SDP answer from Bob. Since a media-relay B2BUA does 
not differentiate between a DTLS message, RTP, or any packet it 
receives, it only changes the transport layer (UDP/TCP) and IP 
headers and forwards the packet towards the other endpoint. The 
B2BUA cannot decrypt the RTP payload, as the payload is encrypted 
using the SRTP keys derived from the DTLS connection setup between 
Alice and Bob. 


If the endpoints use [RFC4474], a B2BUA cannot function as a media- 
relay without violating rule 2 in Section 3. If [SIP-ID] is used, a 
B2BUA can modify the IP address in the c= line and the port in the m= 
line in the SDP as long as it does not otherwise violate rule 3 in 
Section 3. 


5.1.2. RTP- and RTCP-Aware Media-Aware B2BUA 


Unlike the media relay discussed in Section 5.1.1, a media-aware 
relay as defined in Section 3.2.2 of [RFC7092] is aware of the type 
of media traffic it is receiving. There are two types of media-aware 
relays, those that merely inspect the RTP headers and unencrypted 
portions of RTCP packets, and those that inspect and modify the RTP 
headers and unencrypted portions of RTCP packets. 


5.1.2.1. RTP Header and RTCP Packets Inspection 


An RTP-/RICP-aware media relay does not modify the RTP headers and 
RTCP packets but only inspects the packets. Such B2BUAs follow rule 
4 in Section 3 and can continue to do their function while allowing 
end-to-end DTLS-SRTIP. Inspection by the B2BUA will not reveal the 
clear-text for encrypted parts of the SRTP/SRICP packets. 


5.1.2.2. RTP Header and RTCP Packet Modification 


A B2BUA cannot modify RTP headers or RTCP packets, as to do so it 
would need to act as a DTLS endpoint, terminate the DTLS-SRTP 
session, and decrypt/re-encrypt RTP packets. If a B2BUA modifies 
unencrypted or encrypted portions of the RTP or RTCP packets, then 
the integrity check will fail and the packet will be dropped by the 
endpoint. The unencrypted and encrypted portions of the RTP or RTCP 
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packets are integrity protected using the HMAC algorithm negotiated 
during the DTLS handshake (discussed in Section 4.1.2 of [RFC5764]). 
B2BUAs have to follow the rules in Section 3 to avoid breaking the 
integrity of SRTP/SRICP streams. 


6. Forking Considerations 


Due to forking [RFC3261], a SIP request carrying an SDP offer sent by 
an endpoint (offerer) can reach multiple remote endpoints. Asa 
result, multiple DTLS-SRTP sessions can be established, one between 
the endpoint that sent the SIP request and each of the remote 
endpoints that received the request. B2BUAs have to follow rule 1 in 
Section 3 while handling offer/answer and forward the certificate 
fingerprints and SDP setup attributes it received in the SDP answer 
from each endpoint (answerer) unmodified towards the offerer. Since 
each DTLS connection is set up on a unique 5-tuple, B2BUA replaces 
the answerer’s transport addresses in each answer with its unique 
transport addresses so that the offerer can establish a DTLS 
connection with each answerer. The B2BUA, acting as a media relay 
here, follows rule 4 mentioned in Section 3. 


Bob (192.0.2.1:6666) 
/ 
/ 
/ DTLS-SRTP=XXX 
/ 
/ 
DTLS-SRTP=XXX v 
<----------- > (192.0.2.3:7777) 
Alice (192.0.2.0:5555) B2BUA 
<----------- > (192.0.2.3:8888) 
DTLS-SRTP=YYY ^ 
\ 
\ DTLS-SRTP=YYY 
\ 
\ 
\ 
Charlie (192.0.2.2:6666) 


Figure 2: B2BUA Handling Multiple Answers 


For instance, as shown in Figure 2, Alice sends a request with an 
offer and the request is forked. Alice receives answers from both 
Bob and Charlie. The B2BUA advertises different B2BUA transport 
addresses in each answer, as shown in Figure 2, where XXX and YYY 
represent different DTLS-SRTP sessions. The B2BUA replaces Bob’s 
transport address (192.0.2.1:6666) in the answer with its transport 
address (192.0.2.3:7777) and Charlie’s transport address 
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(192.0.2.2:6666) in the answer with its transport address 
(192.0.2.3:8888). The B2BUA tracks the remote sources (Bob and 
Charlie) and associates them to the local sources that are used to 
send packets to Alice. 


7. Security Considerations 


This document describes the behavior B2BUAs must follow to avoid 
breaking end-to-end DTLS-SRIP. Media relays that modify RTP or RTCP, 
or modify SIP header fields or SDP fields that are protected by the 
identity signature, are incompatible with end-to-end DTLS-SRTP. Such 
relays are out of scope for this document. Security considerations 
discussed in [RFC5763] are also applicable to this document. In 
addition, the B2BUA behaviors outlined in this document do not impact 
the security and integrity of a DTLS-SRTP session or the data 
exchanged over it. A malicious B2BUA can try to break into the DTLS 
connection, but such an attack can be prevented using the identity 
validation mechanism discussed in [RFC4474] or [SIP-ID]. Either the 
endpoints or the authentication service proxies involved in the call 
can use the identity validation mechanisms discussed in [RFC4474] or 
[SIP-ID] to validate the identity of peers and detect malicious 
B2BUAs that can attempt to terminate the DTLS connection to decrypt 
the RTP payload. 
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